Hi Oscar et al,

I reviewed this draft and appreciate all the effort that has gone into
it.  
I believe it is on the right track, but does need to resolve a few
issues and clarify a few things before progressing.  I apologize if some
of my comments overlap with those that other's highlighted - I did
review them, but may have missed a few.  Also, I have slightly different
comments on some of the same topics.  I've included the Issues/questions
first, followed by general comments and then editorial nits.

Thanks,
Mary.

========================================================================
=================================

Issues/questions:
-----------------

1) Section 3.2, 2nd paragraph - discussing the five roles - like others
I had some concerns about this text: 
1a) Like Ben, I do wonder if it needs to be normative or whether we need
the text in the second paragraph, particularly given the sentence in the
1st paragraph that "A set of semantics associated with each role is out
of scope of this document".  The 2nd paragraph seems to try to do just
that.  The rest of my comments are premised that this paragraph is still
deemed useful. If not, then you can ignore. 

1b) I'm not entirely convinced of the hierarchy concept, especially when
you bring in the "observer" role. But, see the comment 1e) as this
negates this comment. 

1c) 4th sentence, As far as the "creator" being the 'owner', wouldn't
that be subject to conferencing system policies, as I would think there
would be some systems where the 'owner' would be the administrator?  It
almost seems problematic to make that statement at all, as by defining
'owner' you're implying an additional role.  

1d) 4th sentence, per my general editorial comment #2 below, the terms
in this document should be consistent with the framework.  The term
instantiated in the framework is used when a conference object is
created based on a reservation.  The term that you want to use rather
than "is instantiated" would be "becomes active". I think the point
you're making here is that the creator can modify a conference
reservation.  But, I think the creator should also be able to modify the
conference even after it is active (subject to policy restrictions). 

So, based on comments 1c) an 1d), I would think we might want to change
that 4th sentence from:
OLD:
The
   The "creator" is the 'owner' of the conference and has various
privileges
   which SHOULD allow them to modify the conference variables up to the
   time the conference is instantiated.  
NEW:
   The "creator" of the conference has various privileges
   which SHOULD allow them to modify the conference variables.

1e) I'm also not convinced of the need  for the "observer" role, as it
doesn't so much apply to privileges in terms of changes to the
conference during its lifecycle, but specific media attributes. I would
almost think that an observer is just a hidden participant, perhaps only
visible to the moderator, consistent with the description in the
framework:
"The capability to observe a conference allows a participant with the
 appropriate authority to listen to the conference, typically without
 being an active participant and often as a hidden participant." 

1e) Last sentence.  It might be also useful to clarify that a
conferencing system SHOULD also have at least one of the following
{administrator, creator, moderator or observer} or there's really not
much point in using this framework. I also can't quite see the point in
saying that a conferencing system MAY define the participant role. What
would be the point of a conference that didn't have participants, given
that each user can have multiple roles (e.g., I would think a very
typical set of roles for the moderator would be {creator, moderator,
participant} ).  

2) Section 4.4 (6th para in particular): I also had concerns over the
usage of <moderator-controlled> as a boolean and a value for the
<algorithm>.  Even if you change the names as suggested, it still is
unclear whether the <algorithm> can be "FCFS" or "random" if the
<conference-floor-policy> is "moderator-controlled"?   I would think
not, in which case, is the <conference-floor-policy> really needed or
can you just derive the fact that it's "moderator-controlled" from the
<algorithm>? 

3) Section 4.5.1 <allowed-users-list> [Note: I think Srivatsa also had a
comment on this, but his email specifies section 3.7.1 and Ben also had
a comment on this element]

My initial concern is that this element is overloaded, in that it
defines which users are allowed to be participants in a conference, it
defines the methods by which a user may become a participant in a
conference and it also indicates direct actions needed to be taken by
the focus to add participants to a conference.  I also think there's
some gap in specification.  For example, it seems to me that a user with
a 'method' attribute of "refer" MUST also have a 'method' attribute of
"dial-in" in order to be a participant in the conference (i.e.,
otherwise when the resource initiates the request to join the
conference, how are they allowed to be added OR is the expectation that
there's an indicator that they were referred?).    It also seems that
the use of Refer for SIP really isn't particularly useful - i.e., why
wouldn't the focus just "dial-out" the specified resources. It does make
some sense in the context of alternative communication means.


4) Section 5, page 28, user-admission-policy-type: I'm wondering if
there should also not be a plain "Open" (i.e., no auth required, but NOT
anonymous).  


General editorial comments:
---------------------------

[These are based on reviewing the document for consistency with
terminology in the Centralized Conferencing Framework document]

1) When referencing the framework change the term from "XCON
Conferencing Framework" to "Centralized Conferencing Framework"  [this
was a change made just before it was forwarded to AD for progression]

2) It might be better to change the terms the various stages, for
example in the first paragraph of the introduction, to be consistent
with the framework document (as introduced in the 5th paragraph of
section 3 - Overview), particularly since there is the mapping isn't
clear to me (e.g., what's the difference between started and running) : 
OLD:
  (e.g., reserved, started, running, ended, etc.)
NEW:
  (e.g., created/creation, reserved/reservation, active/activation,
completed/completion)

3) PSTN reference needs to be changed to explicitly refer to Q.931,
ISUP, etc. [another post-WGLC change], for example, 3rd paragraph of the
intro:
OLD:
  (e.g., SIP, H.323, PSTN, etc.)
NEW: 
  (e.g., SIP, H.323, Q.931, ISUP, etc.)
Note: this also impacts the schema.

Nits:
-----
1) Section 2, last paragraph: change "are supposed to" -> "should"

2) Section 3, last sentence:  insert "additional" before "advanced"
since this data model should be provided advanced features beyond those
provided by the data model in RFC 4575:
OLD:
   It is expected that this data model can
   be further extended with new elements in the future in order to
   implement advanced features.
NEW:
   It is expected that this data model can
   be further extended with new elements in the future in order to
   implement additional advanced features.

3) Section 4.1.1,  next to the last paragraph:  is -> are 
"..when users or resources on the <allowed-users-list> is requested..." 

4) Section 4.5, last sentence: shouldn't <conference-description> be
<users> ? 

5) Section 4.5.1, last paragraph: change "difference users" ->
"different users"

_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon